home *** CD-ROM | disk | FTP | other *** search
Text File | 1996-04-25 | 5.6 KB | 141 lines | [TEXT/MPS ] |
- //========================================================================================
- //
- // File: FWArcObj.fr
- // Release Version: $ ODF 1 $
- //
- // Copyright: (c) 1993 - 1996 by Apple Computer, Inc., all rights reserved.
- //
- //========================================================================================
-
- #ifndef FWARCOBJ_FR
- #define FWARCOBJ_FR
-
- #ifndef FWARCOBJ_K
- #include "FWArcObj.k"
- #endif
-
- //========================================================================================
- // Theory of operation
- //
- // The FWStream subsystem can "archive" objects to and from streams. Archiving involves
- // converting an object between it's in-memory layout and a flattened representation.
- // The flattened representation is annotated with information that allows the FWStream
- // subsystem to preserve the runtime type of the object. The format of the annotation
- // is relatively simple.
- //
- // <object-stream> := <class-label> <object-data>
- // <class-label> := <object-header> [ <long ID> ]
- // <object-data> := <object-header> [ <class-specific-data> ]
- // <object-header> := <Tag> <Registry-ID>
- // <Tag> := short integer enumeration { FW_kPrivIDOnly, FW_kPrivIDAndValue }
- // <Registry-ID> := long integer
- //
- // Basically, each archivable object is written as a class "label" followed by the
- // instance data of the object. The label must be specified by the programmer, and
- // is usually closely related to the class name. The label is intentionally not exactly
- // the class name, since by making it independent of the class name we allow for multiple
- // revisions of the class to exist. The class label is written out as an object "header"
- // followed by a pascal string (a length byte followed by a maxium of 255 bytes). The
- // object header is a "tag" which identifies how to interpret the registry-ID and also
- // serves another purpose to be described below. The Registry-ID is usually a
- // positive integer that must be unique per object in the stream. However, the Registry
- // ID may also be an integer that has already been seen earlier in the data stream, in
- // which case there will be no object data following the object header. This is not
- // just a space optimization, it is necessary to prevent a graph data structure from
- // being converted into a tree data structure.
- //
- //========================================================================================
-
-
- //========================================================================================
- // type FW_RObjectWithID
- //========================================================================================
-
- //
- // Both class-labels and object-datas (see above) are tagged with unique IDs.
- // The unique IDs must come from the same ID space.
- // This base type defines the ID space.
- //
-
- type FW_RObjectWithID
- {
- static gUniqueObjectID = 0;
- set gUniqueObjectID = gUniqueObjectID + 1;
- };
-
- //========================================================================================
- // type FW_RArchivableClassHeader
- //========================================================================================
-
- type FW_RArchivableClassHeader : FW_RObjectWithID
- {
- static gClassID = 0;
- set gClassID = gUniqueObjectID;
- ClassTag:
- integer = FW_kPrivIDAndValue;
- ClassID:
- longint = gClassID;
- };
-
- //========================================================================================
- // type FW_RArchivableObjectHeader
- //========================================================================================
-
- type FW_RArchivableObjectHeader : FW_RObjectWithID
- {
- static gObjectID = 0;
- set gObjectID = gUniqueObjectID;
- ObjectTag:
- integer = FW_kPrivIDAndValue;
- ObjectID:
- longint = gObjectID;
- };
-
- //========================================================================================
- // type FW_RArchivableObject
- //========================================================================================
-
- //
- // Any object in a stream is composed of a <class-label> followed by an <object-data>.
- // This type imposes that basic structure.
- //
- // Unfortunately, it's not quite the ideal definition. We currently define this type
- // with an explicit pstring for the class-label string. This precludes the ability
- // to use the object registry for classes that have already been seen in the stream.
- // This is not a serious problem because there is no general way in ODFrc to recognize
- // repeated occurences of class labels. The main problem is that archivable object
- // resource streams are bigger than they need to be due to redundant class labels.
- //
- // We may someday fix the the problem by some clever use of the ability to preregister
- // class labels. This would allow us to generate smaller resources, but would still
- // be backwards compatible with the current format, since the Archiver code already
- // handles both cases.
- //
-
- type FW_RArchivableObject
- {
- FW_RArchivableClassHeader;
- Label:
- longint = 'badl'; // the id for the class-label
- FW_RArchivableObjectHeader; // The object-header for the data to follow (in subtype)
- };
-
- //========================================================================================
- // type FW_RArchivableObjectList
- //========================================================================================
-
- // This definition may be used for any list of archivable objects, but it is better
- // treated as a template. Instead of ObjectArray being an array of FW_RArchivableObject,
- // make it be an array of some subclass of FW_RArchivableObject.
-
- type FW_RArchivableObjectList('oLST') : FW_RArchivableObject(Label='list')
- {
- longint = $$CountOf(ObjectArray);
- array ObjectArray
- {
- FW_RArchivableObject;
- };
- };
-
- #endif
-